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1 Introduction 


The Abstract Plan Preparation Language (APPL) [2] is a planning language inspired by 
the New Domain Description Language (NDDL), a powerful planning language developed 
at NASA Ames [4] which has evolved from the Planning Domain Description Language 
(PDDL)^] 1 . APPL is built around the idea that not all constraints are alike in the spec- 
ification of an AI planning problem. In particular, the APPL language provides a special 
notation for the actions which must be mutually exclusive on a particular timeline. This 
feature enables a more compact specification of actions and states that is similar to the 
specification of state transition systems. 

Because the syntax and semantics of APPL are simpler than those of NDDL, APPL is 
more suitable for formal verification, static analysis, and automated test generation. How- 
ever, the language is much less expressive than NDDL. 

This paper describes the algorithms and techniques used to translate APPL to SAL [3]. 
This translator was developed under the Spacecraft Autonomy for Vehicles and Habitats 
(SAVH) project, whose purpose is to develop verification & validation technology that can 
enable the application of AI planning to man-rated space applications. The long-term goal of 
our research is to develop techniques to verify the correctness of the domain knowledge that 
is typically expressed in planning languages. The key idea is that once the planning domain 
knowledge has been captured in a SAL model, many different properties of that domain can 
be analyzed using the SAL model checker. However, at this point in the SAVH program, 
a target domain has not been developed, so our efforts have centered on the development 
of basic technology. In particular, we have focused on the mechanisms for expressing and 
translating constraints, which are central to the NDDL language. To enable the assessment 
of the power and usefulness of our translators, one verification property is generated. This 
property states that no plan exists that satisfies all of the constraints. The model checker 
is then deployed on this property. If a plan does exist, then the model checker will produce 
a counterexample that is a viable plan that satisfies the constraints. We do not envision 
that this approach will be nearly as efficient or powerful as EUROPA 2. We do believe that 
this translation technology could be useful for establishing that key properties of the domain 
knowledge are true. We think that this approach may one day provide a powerful means for 
debugging the specifications of domain knowledge that are used in safety-critical planning 
systems. 

2 Simple Example 

We will begin our look at the technique for translating APPL to SAL with a very simple 
two timeline example 2 : 

1 PDDL is the planning language of the Extensible Universal Remote Operations Architecture 2 (EUROPA 
2). EUROPA 2 is a component-based software library for constructing highly-tailored, domain-specific 
planners. 

2 We assume a prior knowledge of SAL syntax throughout this document. 
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PLAN exl 


TIMELINE A 
ACTIONS 

AO: [2 , _] 

A1 

A2 

TRANSITIONS 

AO -> A1 -> A2 
END A 

TIMELINE B 
ACTIONS 

BO: [2 , _] 

Bl: [1,10] 

TRANSITIONS 

BO -> Bl 

END B 

INITIAL-STATE 

|-> A. AO 
|-> B.BO 

GOALS 

A. A2 

B. B1 

END exl 

Timeline A has three actions AO, Al, and A2 with only one possible sequence. The duration 
of action AO is at least 2 time units, while the other two actions have no restrictions on their 
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duration. Similarly, timeline B has two actions BO and Bl, with only one possible sequence. 
BO has a duration of at least 2 time units, while Bl takes between 1 and 10 units. 
Corresponding to these actions, the following types are generated 

A_actions: TYPE = {AO, Al, A2, A_null}-; 

B_actions: TYPE = {BO, Bl, B_null}; 

In addition to the declared actions, a null state is created for each of the timelines. There 
are two purposes for these extra states: 

• They provide a means for the completion of an action when the action has no successor. 

• They provide a convenient mechanism for recording when a goal state has been reached 
on each timeline. As shown below, a transition from a timeline’s goal state to the null 
state is generated by the translator. 

The generated SAL model consists of three modules: 

• Module A_m which corresponds to timeline A. 

• Module B_m which corresponds to timeline B. 

• Module Clock which advances time. 

The structure of the module generated for timeline A is: 

A_ra : MODULE = 

BEGIN 

INPUT 

GLOBAL 

LOCAL 

INITIALIZATION 

TRANSITION 

[ 

A0_to_Al: 11 AO -> Al 

[] 

Al_to_A2 : 11 Al -> A2 

[] 

A2_to_A_null : 11 A2 -> A_null 
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] 

END; 0 / 0 °/o A_ra 

Each of these sections is used in the translation: 

• INPUT is used to select values for parameters of actions. 

• GLOBAL is used to hold state values and their current parameter values. 

• LOCAL is used to hold the start time of the currently scheduled action. 

• INITIALIZATION is used to set initial values. 

• TRANSITION specifies rules for transitioning from one action to another. 

The three modules will be asynchronously composed. In SAL this is specified as follows 
System: MODULE = A_m [] B_m [] Clock; 

The SAL tool links the variables named in the GLOBAL and INPUT sections together. In other 
words, variables with the same name are equated even though they are specified in different 
modules. 

The SAL model checker is then used to search through all possible sequences of actions 
on the timelines to find sequences which satisfy all of the constraints specified in the APPL 
model. These constraints fall into two broad categories: 

• Timing constraints that impact durations and start/stop times of actions. 

• Allen operations [1] that specify relationships between time intervals of actions. 

The search is started at time 0 and proceeds forward in time until the planning horizon is 
reached. The stop time is specified via a constant as follows: 

MAX_TM: int = 150; %°/ 0 Always generated 

TM_rng: TYPE = [0 . . MAX_TM] ; 7„°/ 0 Always generated 

The progression of time is controlled by the clock module: 

Clock: MODULE = 

BEGIN 

INPUT 

tm_intv: [1 . . 10] 

OUTPUT 

time: TM_rng 
INITIALIZATION 
time = 0; 

TRANSITION 
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[ 

advance_clock: 

time + tm_intv <= MAX_TM — > time’ = time + tm_intv; 

] 

END; 

This module advances the clock by a value in the range of 1 . . 10. The clock is stored in the 
variable time. Note that since the modules are asynchronously composed, the clock module 
can effectively advance time at any point. Both the A_m and the B_m modules include the 
variable time in their INPUT sections. 

The GLOBAL sections of all of the timeline modules contain variables which record the 
action that is scheduled during the current time: 

GLOBAL 

B_state: B_actions, 

A_state: A_actions 

The durations of the actions are controlled by the use of a start variable declared as 
follows 

LOCAL 

start : TM_rng 
INITIALIZATION 
start = 0; 

Whenever an action is initiated, the initiation time is stored in this variable. The durations 
of an action will be controlled through this variable. This will be explained more carefully 
when we discuss the transitions section. 

The initial actions on a timeline can be specified as follows: 

INITIAL-STATE 

|-> A. AO 
|-> B.BO 

If a timeline’s initial state is not specified, then the model checker will explore all possible 
start states. 

The APPL TRANSITIONS section is the major focus of the translation process. The SAL 
TRANSITIONS section is constructed from this part of the APPL model. For example, the 
following APPL code: 

TRANSITIONS 

AO -> A1 -> A2 
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is translated into the SAL code: 


TRANSITION 

[ 

A0_to_Al: 11 AO -> A1 

A_state = AO 
AND time >= start + 2 
— > 

A_state’ = Al; 
start ’ = time; 

[] 

Al_to_A2 : 11 Al -> A2 

A_state = Al 
— > 

A_state’ = A2; 
start ’ = time; 

[] 

A2_to_A_null : 11 A2 -> A_null 

A_state = A2 
— > 

A_state J = A_null; 

] 

When a transition occurs, an action is completed and another transition is initiated. No 
empty time slots are allowed. The TRANSITIONS section defines three transitions 3 which are 
labeled as follows: 

A0_to_Al: 11 AO -> Al 

Al_to_A2 : 11 Al -> A2 

A2_to_A_null: 11 A2 -> A_null 

The first transition is guarded by the following expression: 

A_state = AO 

AND time >= start + 2 

The first conjunct insures that this transition only applies when the current action on the 
timeline is AO and the second conjunct insures that the duration of the action is at least 2 
time units. This corresponds to the fact that AO was declared as AO : [2 , _] . The expressions 
after the — > specify that the new state is Al and that the start variable is re-initialized. 
The APPL GOALS statement 

3 We have adopted a constructive semantics of allowed transitions: only the transitions that are explicitly 
specified are allowed. The EUROPA 2 system takes the opposite approach. All possible transitions are 
allowed unless specifically ruled out by a constraint. In future versions of the APPL to SAL translator, we 
may add an option that allows one to choose between constructive or destructive semantics. 
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GOALS 

A. A2 

B. B1 

lists the two actions that need to be reached (where the default meaning of the expression 
is the logical conjunction of the terms). This statement is translated into the following SAL 
specification: 

sched_sys: THEOREM 

System |- AG(NOT(A_state = A_null AND B_state = B_null)); 

Since the “null” states can only be reached from the goal states (i.e. A2 and Bl), these 
efficiently record the fact that the appropriate goal has been reached on each timeline. Note 
that the APPL goal statement has been negated. Therefore, when the model checker is 
instructed to establish the property, any counterexample provided by SAL will serve as a 
feasible realization of the plan. If a specific ordering of goal achievement is desired, we can 
add a constraint using Allen operations in the CONSTRAINTS section to accomplish this. For 
example, if goal A2 must be reached before Bl, then the following constraint can be added: 

A.A2 WITH before B.B1 

Allen operations will be discussed in greater detail in Section 3. 

The complete generated SAL model (exl.sal) is: 

*/.•/. File exl.sal 

•/.'/. Generated from exl.appl 

11 On Fri Oct 20 14:14:39 EDT 2006 

11 By APPL-2 .b (08/14/06) 

exl : CONTEXT = 

BEGIN 

INFNTY : int = 1000; 11 Always generated 

MAX_TM: int = 150; 11 Always generated 

TM_rng: TYPE = [0 . . MAX_TM] ; 11 Always generated 

A_actions: TYPE = {A0, Al, A2}; 

B_actions: TYPE = {B0, Bl}; 

A_m : MODULE = 

BEGIN 

INPUT 

time: TM_rng 
GLOBAL 



B_state: B_actions, 

A_state: A_actions 
LOCAL 

start : TM_rng 
INITIALIZATION 
start = 0; 

A_state = AO; 

TRANSITION 

[ 

AO_to_Al: 11 AO -> A1 

A_state = AO 
AND time >= start + 2 
— > 

A_state J = Al; 
start ’ = time; 

[] 

Al_to_A2 : 11 Al -> A2 

A_state = Al 
— > 

A_state J = A2; 
start ’ = time; 

[] 

A2_to_A_null : °/„°/„ A2 -> A_null 

A_state = A2 
— > 

A_state J = A_null; 


] 

END; 11 A_m 

B_m : MODULE = 

BEGIN 

INPUT 

time: TM_rng 
GLOBAL 

A_state: A_actions, 
B_state: B_actions 
LOCAL 

start : TM_rng 
INITIALIZATION 
start = 0; 
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B_state = BO; 

TRANSITION 

[ 

BO_to_Bl: 11 BO -> B1 

B_state = BO 
— > 

B_state J = Bl; 
start’ = time; 

[] 

Bl_to_B_null: 11 Bl -> B_null 

B_state = Bl 
AND time >= start + 1 
AND time <= start + 10 
— > 

B_state’ = B_null; 


] 

END; 11 B_m 


Clock: MODULE = 

BEGIN 

INPUT 

tm_intv: [1 . . 10] 

OUTPUT 

time: TM_rng 
INITIALIZATION 
time = 0; 

TRANSITION 

[ 

advance_clock: 

time + tm_intv <= MAX_TM — > time’ = time + tm_intv; 

] 

END; 

System: MODULE = A_m 
[] B_m 
[] Clock; 

sched_sys: THEOREM 

System |- AG(NOT(A_state = A_null 
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AND B_state = B_null 

)); 


END %°/o exl 

3 Constraints Expressed Through Allen Operations 

The allowed transitions on a timeline can be further restricted through use of Allen opera- 
tions. The following Allen operations are allowed in the APPL language: 

• contains 

• contained_by 

• meets 

• met_by 

• starts 

• equals 

• ends 

• before 

• after 

• overlaps 

In the generated SAL model, these constraints result in additional guards on the transitions 
and additional variable updates. 

3.1 Approach 

In this section, we will explain the translation approach without consideration of action 
parameters. In a later section, we will describe how the action parameters are handled. In 
the first pass of the translator, all of the Allen operations are collected in a data structure 
which stores five key fields: 

• tml_A: Timeline of the first action. 

• act_A: First action. 

• allop: The Allen operation. 

• tml_B: Timeline of the second action. 
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• act_B: Second action. 

For example, the Allen operation 
Nav.X2 starts Instr.Y3 

results in tml_A = Nav, act_A = X2, allop = starts, tml_B = Instr, act_B = Y3. In 

the second pass of the translator, all of these constraints are matched against the transition 
that is being generated. We will use the following notation to represent the transition under 
construction: 

<tml>: <current_action> -> <next_action> 

The current timeline is <tml> and we are processing the transition from <current_action> 
to <next_action>. We will introduce some notation to indicate when there is a “match.” 
A constraint will be denoted as follows: 

tml_A act_A <op> tml_B act_B 

where <op> is one of the Allen ops (e.g. meets, contains, etc). We will express the matching 
requirement by drawing lines between items that must be equal: 

<tml>: <current_action> — > <next_action> 

A 

tml_A act_A <op> tml_B act_B 

This diagram expresses the requirement that <tml> = tml_A and <current_action> = 
act_A. 

The basic approach is as follows. For each transition being generated, the translator 
searches through all of the constraints looking for matches against patterns associated with 
each type of Allen operation. The patterns are used to specify: 

• guards on the transition which occur on the left or pre side of the — > 

• variable updates which occur on the right or post side of the — > 

These “patterns” are described in the next subsections. We will not include the routine 
update of the time variables in the following sections, to simplify the presentation. 

3.2 The contained by Allen Operator: A contained by B 

There are two matching patterns required for the contained_by operation. Suppose we have 
a constraint 

tml_A.act_A contained_by tml_B.act_B 

which can be illustrated as follows: 
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tml_A.act_A 

tml_B.act_B 


While generating any transition of the form <current_action> -> act_A for timeline tml_A, 
a check needs to be made to insure that act_B is already executing on the tml_B timeline. 
Therefore, the following guard is added to the <current_action> -> act_A transition: 

tral_B_state = act_B 

The translator searches through the list of all of the constraints while processing a 
<current_action> -> <next_action> transition. If it finds a constraint with <op> = 
contained_by, tml_A = <tml> and act_A = <next_action>, then this guard is added 
and the net result is: 

tral_A_state = <current_action> ; 
tral_B_state = act_B 

— > 

tral_A_state ’ = act_A; 7„°/ 0 = <next_action> 


This particular match is illustrated below: 

<tml>: <current action> — > cnext action> 



tml_A act_A contained_by tml_B act_B 

It is also necessary to keep act_B from terminating while act_A is still executing. This is 
accomplished using another pattern: 

<tml>: <current action> — > <next action> 



tml_A act_A contained_by tml_B act_B 

In other words for transitions of the form tml_B: act_B -> <next_action> (i.e. where 
<tml> = tml_B and <current_action> = act_B), we must add the following guard: 

AND tml_A_state /= act_A 

The net result is 

tml_B_state = <current_action> ; 

AND tml_A_state /= act_A 

— > 

tml_B_state = act_B %7„ = <next_action> ; 
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3.3 The contains Allen Operation: A contains B 

There are three matching patterns required for the contains operation: 



The first pattern is 

<tml>: <current_action> — > <next_action> 

\ 

tml A act_A contains tml B act B 

Whenever there is a match, shown in this illustration, the following additional guard is added 
to the <current_action> -> <next_action> transition: 

AND tml_B_state /= act_B 

The net result is: 

tral_A_state = act_A; °/„°/„ = <current_action> ; 

AND tml_B_state /= act_B 

— > 

tml_A_state ’ = <next_action> ; 

The reason for this guard is simple. Because tml_A.act_A contains tml_B . act_B , act_A 
cannot be allowed to terminate as long as act_B is still active. But what if act_B never 
executed at all? We do not want the action act_A to terminate until after an action act_B 
has started and completed. So, we need to keep track of this event using a state variable. 
We add a variable act_B_while_act_A to record this information. We then add a test on 
this variable to the transition guard: 

tral_A_state = act_A; °/„°/„ = <current_action> ; 

AND tml_B_state /= act_B 
AND act_B_while_act_A 

— > 

tral_A_state ’ = <next_action> ; 
act_B_while_act_A = false; 

The variable act_B_while_act_A is reset to false in preparation for a future execution of 
the action. The initial value of this variable is set as: 

act_B_while_act_A = (tml_A_state = act_A) AND 

(tral_B_state = act_B) ; 
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The second pattern is 

<tml>: <current action> — > <next action> 



tml A act A contains tml B act B 

When a transition into state act_B occurs, we need to update the value of the variable 
act_B_while_act_A. If action act_A is executing on the other timeline, then the variable 
act_B_while_act_A is set to true as follows: 

IF tml_A_state = act_A THEN 
act_B_while_act_A ) = true; 

ENDIF ; 

The net result is 

tral_B_state = <current_action> ; 

— > 

tral_B_state ’ = act_B °/„7> = <next_action> ; 

act_B_while_act_A ) = IF tml_A_state = act_A THEN 

true 

ELSE 

act_B_while_act_A 

ENDIF; 

where the update syntax is rewritten in a form suitable for SAL. 

The third pattern is 

<tml>: <current_action> — > <next_action> 

\ 

tml A act A contains tml B act B 

When a transition into state act_A occurs, we need to update the value of the variable 
B_while_A if the time has not advanced. If action act_B has just been initiated on timeline 
tml_B, then the variable B_while_A is set to true as follows: 

tral_A_state = <current_action> ; 

— > 

tral_A_state ’ = act_A 7,7, = <next_action> ; 

act_B_while_act_A ) = IF tml_B_state = act_B AND B_start = time THEN 

true 

ELSE 

act_B_while_act_A 

ENDIF; 

It should be noted that this allows equal start times for actions A and B. If a strict “contains” 
is desired, one should leave out the code generated from this last pattern. 
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3.4 The meets Allen Operator: A meets B 

There are two matching patterns required for the meets operation: 

tml_A . act_A tml_B . act_B 

The first one occurs when tml_A.act_A terminates: 

<tml>: <current_action> — > <next_action> 

\ 

tml A act A meets tml B act B 

Whenever there is a match shown in this figure, the following variable update is added to 
the <current_action> -> <next_action> transition: 

tml_B_state’ = act_B; 

The net result is 

tml_A_state = act_A; °/„°/„ = <current_action> ; 

— > 

tml_A_state ) = <next_action> ; 
tml_B_state ) = act_B; 

Thus, whenever act_A terminates, act_B is initiated on timeline tml_B. But, what if the 
currently executing action on timeline tml_B is not an allowed predecessor of act_B? To 
handle that case, we need an additional guard on the <current_action> -> <next_action> 
transition resulting in: 

tml_A_state = act_A; 7„°/ 0 = <current_action> ; 

( tml_B_state = act_PBl OR 
tml_B_state = act_PB2 OR 

tml_B_state = act_PBn ) 

— > 

tml_A_state’ = <next_action> ; 
tml_B_state ) = act_B; 

where act_PBl, act_PB2, . . . act_PBn are all the allowed predecessor actions of act_B. 
It is also necessary to check that the duration constraints on all of these predecessor actions 
are met. These necessitate the use of global start variables: A_ start and B_ start. If there 
were two predecessor actions to act_B, say BO and Bl, we would end up with a guard similar 
to the following: 


16 




( ( B_state = BO 

AND time >= B_start + 0 
AND time <= B_start + 10 
) OR ( B_state = B1 

AND time >= B_start + 5 

) 

) 

It is also necessary to make sure that any constraints on the initiated action on the time- 
line are satisfied. In the above example it is necessary to examine the BO -> act_B and 
B1 -> act_B against all of the Allen operators in the database. This is accomplished by a 
recursive call to the procedure we are describing in this section. 

The semantics of the constraint can be strengthened by matching a second pattern: 

<tml>: <current action> — > cnext action> 


tml A act A meets tml B act B 

When processing the transitions into the act_B action on the tml_B timeline, we update the 
tml_A timeline as well: 

tml_B_state = <current_action> 

AND tml_A_state = act_A; 

— > 

tml_B_state ) = act_B %7„ = <next_action> 

tml_A_state ) IN act_NA_i, ... , act_NA_n; 

where act_NA_i, . . . , act_NA_n are the successor actions of act_A. And, of course, we must 
check that the durations and constraints are satished for this transition as before. 




3.5 The met by Allen Operator: A met by B 

There are two matching patterns needed for the met_by operation: 


tml_A.act_B 


tml_B.act_A 


Whenever the translator finds the following match: 

<tml>: <current action> — > cnext action> 



tml_A act_A met_by tml_B act_B 
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the following variable update is added to the <current_action> -> <next_action> tran- 
sition: 

tml_A_state ’ = act_A; 

In other words, when act_B is terminated on timeline tml_B, action act_A is started on the 
other timeline. This of course, necessitates a check that a predecessor action of act_A is 
currently executing. The net result is: 

tral_B_state = act_B 
( tml_A_state = act_PAl OR 
tml_A_state = act_PA2 OR 

tml_A_state = act_PAn 

) 

— > 

tml_B_state ) = <next_action> 
tral_A_state ’ = act_A; 

where act_PAl, act_PA2, . . . , act_PAn are the predecessor actions of act_A. 

Also it is necessary to match transitions on the other timeline as well: 

<tml>: <current_action> — > <next_action> 

\ 

tml_A act_A met_by tml_B act_B 

In other words, we can allow entrance into state act_A, if action act_B is currently executing. 
Therefore, the following guard must be added: 

tml_B_state = act_B 

Since act_A is met by act_B, it is necessary that act_B be terminated with an update to 

tml_B_state: 

tml_B_state’ IN {act_NBl, .., act_NBn}; 

where NB_i, .., NB_n are the successor actions of act_B. The net result is 

tral_A_state = act_A; 7„°/ 0 = <current_action> ; 

tral_B_state = act_B 

— > 

tml_A_state ) = <next_action> ; 

tral_B_state ’ IN {act_NBl, act_NB2, ...act_NBn}- ; 

So whenever act_A is terminated, act_B is initiated. And of course we must check that the 
durations and constraints are satisfied for this transition as in the meets operator. 
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3.6 The starts Allen Operator: A starts B 

There is just one matching pattern needed for the starts operation: 


tml_A.act_A 

tml_B.act_B 


Whenever there is a match 

<tml>: <current_action> — > <next_action> 

\ 

tml A act A starts tml B act B 

the following variable update is added to the <current_action> -> <next_action> tran- 
sition: 



tml_B_state’ = act_B; 

The net result is 

tral_A_state = <current_action> ; 

( tml_B_state = act_PBl OR 
tml_B_state = act_PB2 OR 

tml_B_state = act_PBn 

) 

— > 

tral_A_state ’ = act_A; °/ 0 % = <next_action> 

tml_B_state ’ = act_B; 

where act_PBl, act_PB2, . . . act_PBn arc all of the allowed predecessor actions of act_B. 
So, whenever act_A is initiated, act_B is also initiated, and this transition is guarded with 
the requirement that a predecessor action of act_B is executing. 

There is a semantics issue that arises here: whether or not act_B can be scheduled 
without act_A being started. For example, does the following timeline trace 


A: 

A1 

1 A3 | 

B: 

B1 

1 B2 | 


satisfy the constraints 
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A1 -> (A2 | A3 ) 


B1 -> B2 

A.A2 starts B.B2 

In this trace, A2 does not execute. Since the semantics of A op B is FORALL A EXISTS B, the 
above trace represents a vacuous solution and hence does meet the constraint. 

3.7 The ends Allen Operator: A ends B 

There is just one matching pattern needed for the ends operation: 

tml_A.act_A 

tml_B.act_B 

Whenever there is a match 

<tml>: <current_action> — > <next_action> 

\ 

tml A act A ends tml B act B 

action act_B has to be terminated along with action act_A. The net result is: 

tral_A_state = act_A; 7„°/ 0 = <current_action> 

tral_B_state = act_B 

— > 

tral_A_state ’ = <next_action> ; 

tral_B_state ’ IN act_NBl, act_NB2, ..., act_NBn; 

where act_NBl, act_NB2, . . . , act_NBn are all of the allowed successor actions of act_B. So, 
whenever act_A is terminated act_B is also terminated and a successor action is initiated. 
If there is no successor state for act_B, then the guard is falsified with the addition of 

AND FALSE 

If the guard is falsified, then act_A is never allowed to terminate. 

3.8 The equals Allen Operator: A equals B 

The equals operator 



is implemented as the combination of starts and ends. In other words, the Allen operation 
A equals B is internally translated into A starts B and A ends B. 
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3.9 The before Allen Operator: A before B 

The remaining three operators - before, after, and overlaps - require that additional 
variables be introduced in the SAL model in order to enforce the desired behavior. For 
example, to ensure that action act_l occurs before act_2, a variable must be used to record 
the fact that act_l has occurred some time in the past. One extra variable is needed for 
each before constraint, because the variable that enforces act_l before act_2 does not 
help in establishing act_3 before act_4. 

The model generator has a mechanism for creating unique variable names, so that no 
name collision is possible when dealing with multiple constraints. The operator names and 
the actions’ names and parameters that are involved are part of this identifier. 

There are two matching patterns required for the before operation: 

tml_A.act_A tml_B.act_B 

For example, the before constraint 

tml_A.act_A before tml_B.act_B 

a Boolean variable tml_A_act_A_bef ore_tml_B_act_B is declared and initialized as FALSE. 

Then, whenever there is a match: 

<tml>: <current_action> — > <next_action> 

\ t 

\ I 

tml A act A before tml B act B 

the fact that tral_A.act_A has occurred is recorded: 

tral_A_state = act_A; 7„°/ 0 = <current_action> 

— > 

tral_A_state ’ = <next_action> ; 
tral_A_act_A_bef ore_tml_B_act_B ) = true 

Also, action act_B cannot be executed unless action act_A has executed in the past. So 
whenever there is a match: 

<tml>: <current action> — > cnext action> 



tml A act A before tml B act B 

the following code is generated: 

tml_B_state = <current_action> 

AND tml_A_act_A_bef ore_tml_B_act_B 

— > 

tral_B_state ’ = act_B; 
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Another semantics issue is raised here. The mechanism for recording the occurrence of 
act_A can be modified so that it is matched repeatedly (by resetting the history variable) 
or just once (without resets). These two interpretations correspond to two distinct views 
of the Allen operator semantics. There is no clear indication as to which approach is to be 
preferred. The current implementation accepts a timeline where action act_B never occurs. 
This is a weaker constraint than requiring that for each act_A, there should necessarily be 
a matching occurrence of act_B. The current implementation is also strict. In other words, 
if A meets B, then A before B is not true. 


3.10 The after Allen Operator: A after B 

The after operator 


tml_A.act_A 


tml_B.act_B 


is the dual of the before operator, i.e. the code generated for the constraint act_A before act_B 
is identical to that for act_B after act_A. Hence, the code generation is very similar to 
the above: an additional history variable is needed to record the occurrence of act_A, when 
leaving the state act_A, this fact is recorded in the history variable. Any transition into 
act_B is then guarded by the condition that the history variable is true. 


3.11 The overlaps Allen Operator: A overlaps B 

The constraint act_A overlaps act_B 


tml_A.act_A 



tml_B.act_B 


or 



tml_A.act_A 

tml_B.act_B 



can be satisfied by two scenarios: 

• act_A occurs first, then the system needs to traverse the following sequence of states 
and no other: act_B starts, act_A ends, and afterwards act_B ends. 

• act_B occurs first, then the only allowed sequence is: act_A starts, act_B ends, and 
then act_A ends. 

Monitoring the correct succession of states can be enforced by using one additional variable 
that records either one of the above initial events and then the subsequent intermediate 
states that are traversed. Alternatively, we can use two Boolean variables to record which 
one of the initial conditions has occurred: has act_A happened first or act_B? 

There are four separate match patterns that generate code for an overlaps constraint. 
More precisely we can be either entering or leaving either act_A or act_B. The first pattern 
is 
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<tml>: <current action> — > <next_action> 

tml_B act_B 

11 = <current_action> 

The second pattern is: 

<tml>: <current action> — > cnext action> 



tml_A act_A overlaps tml_B act_B 

The code generated for the second pattern is: 

tral_A_state = <current_action> 

— > 

tml_A_state ) = act_A 11 = <next_action> 

act_A_f irst_overlaps_act_B ’ = NOT act_B_f irst_overlaps_act_A 

The third pattern is 

<current action> — > cnext action> 



tml_A act_A overlaps tml_B act_B 

The code generated for the third pattern is: 

tral_B_state = <current_action> 

— > 

tml_B_state’ = act_B; %% = <next_action> 

act_B_f irst_overlaps_act_A’ = NOT act_A_f irst_overlaps_act_B 

The fourth pattern is 

<tml>: ccurrent action> — > cnext action> 



tml_A act_A overlaps tml_B act_B 


tml_A act_A overlaps 

The code generated for the first pattern is: 

tral_A_state = act_A 

AND act_A_f irst_overlaps_act_B 


— > 


tml_A_state ’ = <next_action> ; 
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The code generated for the fourth pattern is: 


tral_B_state = act_B 

AND act_B_f irst_overlaps_act_A 

tral_B_state ’ = <next_action> ; 


4 Transition Parameters 

The processing of action parameters results in additional guards and variable updates. Con- 
sider the following example transition 

A1 (xx,yy , _ , ww) -> A2(_,yy,ww) 

where the matching of parameter names indicates a constraint on the transition. For each 
matching argument, it is necessary to generate a variable to hold the value of that matched 
parameter. The translator creates a variable name by concatenating the parameter identifier 
to the action name. For example, if the A1 and A2 actions were defined as follows: 

Al(pl: typel, p2 : type2, p3 : type3, p4: type4) 

A2(pl: typel, p2 : type2, px: type4) 

the translator will generate the following GLOBAL variables: 

Al_p2: type2; 

Al_p4: type4; 

A2_p2: type2; 

A2_px: type4; 

Note that variables are only created where needed, namely where there is a match. The 
transition statement equates these parameters as follows: 

Al_p2 = A2_p2 
Al_p4 = A2_px 

These parameter matchings can be generated on the pre side, such as 

Al_p2 = A2_p2 ’ AND Al_p4 = A2_px> 

or the post side 

A2_p2 ’ = Al_p2 ; 

A2_px ’ = Al_p4; 
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The primes indicate that these are the values of the variables after the update. The advantage 
of the post form is that it directly selects the new values for the parameters after the 
transition. However, in the presence of multiple constraints it is possible to have multiple 
updates on the same parameter: 

Al_p2 ’ = A2_p2 ; 

Al_p2 ’ = B3_p2 ; 

This construction is not allowed in SAL, while the pre version is allowed: 

Al_p2 ’ = A2_p2 AND Al_p2’ = B3_p2 

Although it is necessary to actually update the variables, the pre form is deployed as much 
as possible to avoid illegal updates. 

5 Constraint Parameters 

The impact of parameters on the Allen operation constraints is very complicated. In fact, 
many subtle semantics issues arise here. These will not be dealt with in detail in this 
paper. Instead, we will present a few examples of how parameter processing is done, without 
attempting to be complete. 

For convenience, we will restrict our attention to two timelines A and B with actions 
Al, A2, ... and Bl, B2, ... For simplicity, we will not address the processing of the action 
durations in the following subsections. Also for simplicity we will assume that all actions 
have the following parameter identifiers: x: animals, y: animals, z: animals. For example: 

Al(x: animals, y: animals, z: animals) 

A2(x: animals, y: animals) 

B4(x: animals, y: animals) 

5.1 Example 1 — Parameter Matching 

Suppose we have the following transitions with matching parameters: 

Al(xx) -> A2(_,xx) 

Bl(aa,_) -> B2(_,aa) 

A.Al(aaa) WITH meets B.B2(fish,aaa) 

When processing the Al(xx) -> A2(_,xx) transition, we must first handle the matching 
parameter as follows: 

A_state = Al 
— > 

A_state’ = A2; 

A2_y ’ = Al_x; 
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Next, we need to make sure that the meets constraint is satisfied. Therefore, the B2 action 
must be initiated as well. 

A_state = A1 
AND B_state = B1 
— > 

A_state’ = A2; 

B_state’ = B2; 

A2_y ’ = Al_x; 

Notice the presence of the guard AND B_state = Bl, which insures that the appropriate pre- 
decessor state of B2 is executing. Next, we need to make sure that the parameter matchings 
of the meets constraint are satisfied: 

A_state = A1 
AND B_state = Bl 

AND B2_x’ = fish 
AND B2_y> = Al_x 

— > 

A_state’ = A2; 

B_state’ = B2; 

A2_y ’ = Al_x; 

These guards are indented for easy recognition. Finally, we must make sure that the 
Bl(aa,_) -> B2(_,aa) transition rules are observed: 

A_state = A1 
AND B_state = Bl 

AND B2_x> = fish 
AND B2_y> = Al_x 

— > 

A_state’ = A2; 

B_state J = B2; 

B2_y ’ = Bl_x; 

A2_y ’ = Al_x; 

The A.Al(aaa) WITH meets B . B2 (f ish, aaa) constraint must also be considered when 
processing the transition from Bl -> B2. Clearly, the system should be able to make this 
transition when the action on the A timeline is Al. But what if the current action on the A 
timeline is not Al? Although we can envision solutions where Bl proceeds to B2 and the A 
timeline remains in state Al awaiting a future B2 to meet, why not take advantage of this 
situation and transition Al to A2 along with the Bl to B2 transition (and thus satisfy this 
Allen op constraint immediately)? 

Bl_to_B2 : °///o Bl -> B2 
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B_state = B1 

AND (A_state = A1 => ( TRUE 
AND Al_x’ = A2_y ’ 

AND B2_x ’ = fish 
AND B2_y> = Al_x )) 

— > 

B_state J = B2; 

IF A_state = A1 THEN 
A2_y ’ = Al_x ; 

A_state’ = A2; 

ENDIF 

B2_y ’ = Bl_x; 

B2_x’ IN {x: animals | true}; 

Notice that the guard contains the following conditional (A_state = A1 => . . . . If 
this conditional is true, then the constraints associated with the transition from A1 to A2 
are enforced by some further equalities after the conditional and with some variable updates 
inside an IF-THEN-ELSE. Note that if the Allen operation contains some constant parameters 
in the first action (e.g. A.Al(fish) WITH meets B.B2 , this is handled by adding a term to 
the conditional as follows (A_state = A1 AND Al_x = fish) => ... . 

5.2 Example 2 — Constant Parameters 

Al(xx,_,_) -> A2(_,xx) -> A3 

BO -> B1 -> B2 (dog, _ , _) 

A.A2 starts B.B2(_, cat, donkey) 
when processing A1 -> A2, the following will be generated: 

A_state = A1 
AND B_state = B1 

AND B2_y’ = cat AND B2_z’ = donkey 
— > 

A_state’ = A2; 

B_state’ = B2; 

B2_x’ = dog; 

B2_y’ IN {x: animals | true} 

B2_z’ IN {x: animals | true} 

A2_y ’ = Al_x; 

A2_x’ IN {x: animals | true} 
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The guard AND B2_y’ = cat AND B2_z’ = donkey insures that the constant parameters of 
B.B2 in the Allen operation are properly set. The variable update B2_x J = dog insures that 
the B timeline transition constraints are met. The last two variable updates insure that the 
A timeline constraints are met. Note that the A2_x J IN {x: animals | true} update occurs 
because of the in the first parameter position of the A2 action. Also note that although 
the B2_y and B2_z parameters could be updated as follows: 

B2_y J = cat; 

B2_z’ = donkey; 

If the following additional constraint were present 

Bl(mm) -> B2(dog,mm,_) 

we would obtain two different updates of B2_y: 

B2_y’ = cat; 

B2_y ’ = Bl_x ; 

which is not allowed in SAL. 

5.3 Example 3 — Constant Parameters 

Al(mm) -> A2(_,mm) -> A3 

BO -> B1 -> B2 -> B3 

A.A2(dog,ww) WITH contains B.B2(ww,_) 

When processing A2 -> A3, the following is generated: 

A_state = A2 
AND (A2_x = dog 

=> (NOT (B_state = B2 

AND B2_x = A2_y) ) 

AND B2_while_A2 ) 

— > 

A_state’ = A3; 

The first thing to note is that the guard has an implication (=>). Thus, the requirement that 
A2 contains B2 is only enforced when the first parameter of A2 is dog. Therefore if an A2 is 
executing with a first parameter that is not equal to dog, there is no constraint that it must 
contain B2. If the first parameter of A2 is equal to dog, then the transition is not allowed to 
occur as long as B_state = B2 AND B2_x = A2_y is true. 

If the A timeline transitions were modified to: 



Al(mm) -> A2(dog,mm) -> A3 

then the following would be generated 

A_state = A2 
AND A2_x = dog 
AND (A2_x = dog 

=> (NOT (B_state = B2 

AND B2_x = A2_y) 

) 

) 

AND B2_while_A2 
— > 

A_state’ = A3; 

This is logically equivalent to 

A_state = A2 AND A2_x = dog 

AND (NOT (B_state = B2 AND B2_x = A2_y) 

AND B2_while_A2 
— > 

A_state’ = A3; 

but the translator does not perform this optimization. 

The B1 -> B2 transition is 

B_state = B1 
— > 

B_state’ = B2; 

IF A_state = A2 AND A2_x = dog AND B2_x’ = A2_y THEN 
B2_while_A2 ) = true; 

ENDIF ; 

B2_x’ IN {x: animals | true}; 

Another issue that arises is whether the contains operation should be strict containment or 
whether equal starting or end times should be allowed. The mechanisms described previously 
for contains, have allowed equal start or end times. 

5.4 Example 4 — Constant Parameters 

AO(xx) -> Al(xx,_) -> A2(_,xx) -> Al(_,xx) 

A2(dog,_) -> A3 

BO -> B1 -> BO 
B1 -> B2 -> B3 

A.A2(dog,qq) meets B.B2(qq) 
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When generating a transition from A2 to A1 we get: 

A_state = A2 

AND (A2_x = dog => (B_state = B1 

AND B2_x ’ = A2_y) ) 

— > 

A_state’ = Al; 

Al_y ’ = A2_y ; 

Al_x’ IN {x: animals | true} 

IF A2_x = dog THEN 
B_state’ = B2; 

B_start ; = time; 

ENDIF ; 

This IF THEN ENDIF construct is not supported in SAL. Therefore, it is translated into the 
following in a third pass of the translator. 

B_state’ = IF A2_x = dog THEN B2 ELSE B_state ENDIF; 

The IF THEN ENDIF version is available in an auxiliary *.sll output hie. This hie is often 
easier on human eyes than the final *.sal hie. 

When generating a transition from B1 to B2 we get: 

B_state = B1 

AND ((A_state = A2 AND A2_x = dog) => 

( ( A_state’ = Al => A2_y’ = Al_y’ ) 

AND ( A_state’ = A3 => A2_x = dog ) 

AND B2_x ’ = A2_y 

)) 

— > 

B_state’ = B2; 

IF A_state = A2 AND A2_x = dog THEN 
IF A_state J = Al THEN 
Al_y ’ = A2_y ; 

ENDIF 

A_state’ IN {Al, A3}; 

ENDIF 

B2_x’ IN {x: animals | true}; 


6 Processing IF THEN ELSE expressions 

The specification of an action allows a WITH clause with an “if then else” expression. In each 
branch, there can be different constraints. But let’s start with a simple case: 
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A2(x,y: animals) : 

WITH 

if x = gorilla then 
starts B.B2(fish,x,y) 
else 

starts B . B2 (cat , horse , fish) 
endif 

Now suppose the transitions are constrained as follows: 

Al(xx,_,_) -> A2(xx,_) -> A1 -> A3 

BO -> B1 -> B2 

Then the following is generated for the A1 to A2 transition 

A_state = A1 

AND (A2_x = gorilla 

=> (B_state = B1 AND B2_x’ = fish 
AND B2_y ’ = A2_x’ 

AND B2_z ’ = A2_y ’ ) 

) 

AND (NOT A2_x = gorilla 
=> (B_state = B1 

AND B2_x ’ = cat AND B2_y’ = horse AND B2_z’ = fish) 

— > 

A_state’ = A2; 
start’ = time; 

B_state’ = B2 
A2_x’ = Al_x; 

A2_y’ IN {x: animals | true} 

Nested £i if then else” expressions are a bit more tricky to handle. Consider the following 
example: 

Al(x,y: animals) 

WITH 

if x = cat then 

contains B.Bl(_,dog) 

else 

if y = dog then 

contains B . B2 (cat fish) 
else 

meets B.B2(_, horse, cat) 
endif 
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endif 


A2(x,y: animals) 
with the following transitions 

AO -> Al(dog,y) -> A2(_,y) 


BO -> Bl(aa,_) -> B2(dog,aa,aa) 

The transition from A1 to A2 is generated (omitting timing) as follows: 


A_state = A1 
AND Al_x = dog 
AND (Al_x = cat 

=> (NOT (B_state = B1 AND Bl_y = dog ) ) 

) 

AND (Al_y = dog AND NOT Al_x = cat 

=> (NOT (B_state = B2 AND B2_x = cat AND B2_z = fish )) 

) 

AND (NOT Al_y = dog AND NOT Al_x = cat 
=> (B_state = B1 AND 

(Al_y = dog AND NOT Al_x = cat 
=> (A_state = A1 AND B2_x’ = cat AND B2_z’ = fish) 

) 

AND Bl_x = B2_y J 
AND Bl_x = B2_z ’ 

AND B2_y’ = horse AND B2_z’ = cat 

) 


A_state J = A2; 

A_start J = time; 

IF NOT Al_y = dog AND NOT Al_x = cat THEN 
B_state’ = B2; 

B2_x’ = dog; 

B2_y> = Bl_x; 

B2_z ’ = Bl_x; 

ENDIF; 

A2_y ’ = Al_y ; 
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7 Semantic Subtleties 


In the development of the translator, several subtle issues associated with the exact meaning 
of the Allen operations were discovered. In this section, we will explore some of these. 

7.1 Non-scheduled Actions and Vacuous Solutions 

Suppose we have two timelines A and B with the following actions and allowed sequences: 


AO 

-> 

(Al | 

A2) 

Al 

-> 

A2 


BO 

-> 

Bl -> 

B2 

BO 

-> 

B2 



The two transitions from BO represent alternatives and are equivalent to BO -> (B1 I B2) in 
APPL. Now consider the following Allen operation: 

A1 WITH ends B1 

The following time sequences clearly satisfy the ends constraint: 


AO 

I Al 

1 A2 I 

BO 

1 Bl 

1 B2 I 


Now suppose that A1 never executes. Is the Allen operation satisfied in this case? Based upon 
preliminary experimentation, it appears that the EURO PA 2 planner allows such “vacuous” 
solutions. 

Now suppose that B1 is not executing at the time A1 is executing as in the following 
timeline sequence: 


Al 


1 A2 I 

BO 

I B2 

1 


Does this satisfy the constraint? Based upon preliminary experimentation, the EUROPA 2 
planner requires that the B1 action be explicitly scheduled and must end with Al. In fact, if 
there are multiple Als, each must end its own Bl. 

Therefore, given an Allen operation A op B, we can express the meaning as follows: 

FORALL A: EXISTS B: A op B 
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7.2 Multiple Invocations with After Constraints 

Consider the following Allen Operation 
A1 before B2 

Does the following timeline meet this condition? 


I A1 

I A2 


1 

I B1 

I B2 

1 B3 

1 B2 | 


or must there be an A1 before every B2? 


I A1 

I A2 


1 A1 | 

A2 I 

I B1 

I B2 

I B3 


1 B2 | 


Based upon our experimentation with EUROPA 2, the first timeline appears to be adequate. 
This is consistent with the FORALL-EXISTS semantics given above. 

7.3 Terminal States 

Suppose we have the following Allen operation: 

A1 meets B2 

If A 1 never transitions to A2 (i.e. it is still active at HorizonEnd), is the following an 
acceptable solution? 


A1 (horse) 



Idle | B1 (horse, _) 

I B2 (dog, horse) 



EUROPA 2 accepts this as a valid plan. It should be noted that this is a violation of the 
FORALL-EXISTS semantics. Therefore, the user of the Allen operators needs to remem- 
ber that the FORALL-EXISTS semantics does not apply at the beginning and end of the 
timelines. 
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7.4 Parameters 


The presence of parameters significantly complicates the semantics of the Allen operators. 
There are three categories to consider: 

• constant parameters, e.g. A1 (horse) 

• matching parameters, e.g. Al(mmm) meets B4(mmm) 

• wild card parameters, e.g. Al(_) 
and combinations of these. 

7.4.1 Constant Parameters 

Suppose we have the following Allen operation: 

Al(cat) WITH ends B1 

Does the following timeline satisfy this specification? 


Al (horse) 

I A2 


Idle | Bl (horse) 

I B2 (dog, horse) 



In other words, is this an allowable vacuous solution? In EUROPA 2, the answer is yes. The 
constant parameter can be thought of as a name extension, e.g. Al_cat. The semantics is 
thus: 

FORALL A_cat: EXISTS B: A_cat op B 

Therefore, given two actions 

A(pl ,p2 , . . . ,pn: type) 

B(ql,q2, . . . ,qm: type) 

and the following Allen operation 

A(al,a2, . . . ,an) op B(bl,b2, . . . ,bm) 

where all of the arguments are constant parameters, the meaning is as follows: 

FORALL A: pi = al AND p2 = a2 AND ... AND pn = an 
-> EXISTS B, bl, b2 , . . . , bm: 

A [pi , ... , pn] (al , a2 , . . . , an) op B [pi , . . . , pn] (bl , b2 , . . . , bm) 
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7.4.2 Matching and Wild Card Parameters 

Matching parameters do not restrict the domain of application of the Allen operation. In- 
stead they constrain the allowed values of an acceptable plan. Therefore given two actions 

A(pl ,p2 , . . . ,pn: type) 

B(ql,q2, . . . ,qm: type) 

and the following Allen operation 

A(xx, _ ,yy_ , ... ) op B(_,yy,_,_,xx, ...) 

where the xx and yy are matching parameters. The meaning is as follows: 

FORALL A: EXISTS B, xx, yy: 

A(xx,_,yy_, ... ) op B(_,yy,_,_,xx, ...) 

7.5 Loss of Allen Op Symmetry 

When the definitions of the Allen Operations are presented graphically as in Figure 1, one 
would expect that there would be a symmetry between many of the Allen ops. For example, 
A contains B if and only if B is contained_by A. While this is true of any single pair of 
action intervals, the symmetry does not hold when used to describe a domain model. The 
reason is that there is an implicit quantification over many instances of these actions. For 
example, consider the following specification: 

A1 meets B2 

The following plan satisfies this specification: 


A1 




I A2 

Idle 

I B1 

I B2 

I B1 

I B2 


But, this plan is not satisfied if the above Allen operation is replaced by its dual: 

B2 met_by A1 

This observation is consistent with the FORALL-EXISTS semantics discussed previously. 


36 



A meets B 

A met_by B 
A contains B 

A contained_by B 
A starts B 
A ends B 

A equals B 

A before B 
A after B 

A overlaps B 



Figure 1: Graphical Definition of Allen Operations 
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8 Observations and Conclusions 


The goal of this work was to develop a capability to translate planning problems specified in 
the APPL language into the input language of the SAL model checker. This capability was 
intended to be used in conjunction with another translator from the APPL language to the 
input language of the EUROPA planning system. Together these translators should enable 
the formal verification of key properties of a plan specification, especially the specification 
of a generic domain model. 

During the development of this translator, our understanding of plan specification using 
Allen Operations has greatly increased. We believe we are now in the position to make some 
observations about the advantages and disadvantages of specifying planning problems using 
a language built around Allen Operations. 

The first observation is that it is easy to construct plan specifications that have no 
solution. For example, consider the following constraints 

A meets B 
C met_by A 

These constraints require that A must be followed by both B and C, which is impossible. This 
might be obvious if the constraints are relatively close to each other in a plan specification, 
but what if they are several pages apart? Would this contradiction be detected? What might 
be intended by the above specification is that in some situations one constraint must hold 
and in another situation the other must hold. This can be accomplished using an if-then-else 
structure as follows 

if (condition_l) then 
A meets B 
else 

C met_by A 
endif 

Of course, this requires bringing these previously separate specifications together in one 
place. This, in turn, may make the local specifications less clear. 

The second observation is that the FORALL- EXISTS semantics is somewhat non-intuitive. 
When one first encounters the Allen operations, one would naturally expect that A meets B 
and B met_by A are duals. In other words, they specify the same thing. But as shown in 
Section 7, this is not the case. Therefore, one must be very careful when using Allen ops to 
keep in mind the FORALL-EXIST meaning and not rely on the English language meaning. 
Also, the fact that a constraint can be satisfied vacuously can be non-intuitive. If you have 

A(dog) meets C 

you can easily fall into the trap of thinking that a solution plan will have an A (dog) action 
that is followed by a C action. However, it is perfectly acceptable for the planner to deliver a 
solution with A (cat) and never schedule an A (dog) . Furthermore, there are some exceptions 
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to this FORALL-EXISTS semantics, which complicate our understanding. In particular, at 
the beginning and end of the planning horizon, the EXISTS <constraint> clause need not 
apply. A good example of this is 

At meets Going 
Going meets At 

The last Going or At on a timeline need not satisfy this constraint. Similarly the first Going 
or At on a timeline need not satisfy the following constraint: 

At met_by Going 
Going met_by At 

The third observation is that the use of multiple Allen Operations can have complex 
interactions. For example: 

A starts B2 
B2 met_by B1 

Here we declare that every time an A starts, a B2 must also start. But the second constraint 
requires that B2 be immediately preceded by Bl. So the second constraint interacts with the 
Erst one as a kind of guard: A cannot be scheduled unless Bl is already executing, and as 
soon as A starts, Bl must terminate. Note that the declaration 

A starts B2 
Bl meets B2 

which looks very similar, has a very different kind of interaction. Here, A is free to initiate 
at any time and if Bl is executing at the time that A starts, then the planner could either 
satisfy the second constraint at this point (by terminating Bl and starting B2) or by letting 
Bl continue until a second B2 executes. All of these possibilities must be considered when 
writing a domain specification. 

The fourth observation is that Allen Operations do not provide a good means of desig- 
nating a precise sequence of actions. Consider the following APPL construct: 

A1 -> A2 -> A3 -> A4 

This declaration provides a concise way of saying exactly what sequence of actions can occur. 
This can be partially accomplished by the following Allen Operations: 

A1 meets A2 
A2 meets A3 
A3 meets A4 


However, one problem remains. The fact that there can be no successor to A4 is not specified. 
Furthermore, merely making A4 a goal state does not accomplish this because 
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A1 -> A2 -> A3 -> A4 -> A3 -> A4 


is a solution to the above Allen op specification. In EUROPA one can designate this terminal 
state by stating that the A4 must always be at the end of the timeline. But note that this is 
not a solution that uses Allen ops alone. 

The fifth observation is that Allen Operations do not provide a good means of designating 
a restricted sequence of actions, because they can have non-local interactions and can be 
spread throughout a specification. Consider the following APPL construct: 

A1 -> (A2 | A3 | A4) -> A5 

The following Allen ops can accomplish this 

if x = 1 then 
A1 meets A2 
elsif x = 2 then 
A1 meets A3 
else 

A1 meets A4 
endif 

A2 meets A5 
A3 meets A5 

A4 meets A5 

Now suppose we specify, in a different place, that the timeline must begin with AO and that 

A1 is met_by AO: 

A1 met_by AO 

Together, one might expect that this specifies that exactly one of the following sequences 
must occur: 

AO -> A1 -> A2 -> A5 

AO -> A1 -> A3 -> A5 

AO -> A1 -> A4 -> A5 

But this specification does not rule out 
AO -> A3 -> A5 

AO -> A4 -> A5 

AO -> A5 
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Of course, the addition of AO meets A1 would solve the problem, but this demonstrates how 
careful one must be when using Allen ops to specify a restricted sequence of operations. 

The development of the APPL -> SAL translator was driven by the need to match the 
APPL -> NDDL semantics. Several things made this difficult. First, we did not have a formal 
semantics for NDDL, so we had to infer the meaning of NDDL by executing ELIROPA on 
test problems. The FORALL-EXISTS semantics and end-case exceptions were discovered as 
we built the translator. Second, we discovered that the ELIROPA semantics did not match 
onr original understanding, so there is a structural mis-match between APPL and ELIROPA. 
In particular, we had not originally envisioned that ELIROPA employs a kind of inclusive 4 
approach to specifying the allowed set of actions on a timeline. In ELIROPA, any action 
can be followed by any other action, unless it is prohibited from doing so by a constraint 
(e.g. an Allen Operation). However, APPL was designed around the idea of a state machine 
where all of the transitions are enumerated. In this constructive approach, an action can 
only be followed by another action if it is specifically included in the specification. In the 
end, we were able to bring these two translators fairly close together with the addition of null 
states, but we are not completely satisfied with onr current solution. Third, the interaction 
of Allen Operations was much more complex than we envisioned. These interactions led 
to far more complicated code than we originally expected. Furthermore, we often had to 
rework the translation scheme as we discovered how EUROPA handled these interactions. 
For that reason, we do not have confidence that the translator is sound. At best, we have 
produced a rapid prototype which can serve as a basis for future developments. The authors 
hope that the techniques described in this paper will be useful to future developers who seek 
to connect planning languages to symbolic model checkers. 
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